Undo/redo architecture across multiple files

ABSTRACT

Editing operations are monitored for operations for which information must be stored in order to properly apply an undo or undo/redo sequence to plurality of files. A snapshot is taken and persisted before such an operation is performed. Upon the execution of an undo or redo command, the persisted snapshot is retrieved and applied to the newly generated editing element.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is a continuation of U.S. patent applicationSer. No. 10/165,749 filed Jun. 7, 2002, entitled “UNDO/REDO ARCHITECTUREACROSS MULTIPLES FILES” which is hereby incorporated by reference in itsentirety.

COPYRIGHT NOTICE/PERMISSION

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent files or records, but otherwise reserves all copyrightrights whatsoever. The following notice applies to the software and dataas described below and in the drawings hereto: Copyright© 2002,Microsoft Corporation, All Rights Reserved.

TECHNICAL FIELD

This invention relates to the field of computing and in particular tothe field of editing tools.

BACKGROUND

In some editors it is possible to “back out” and “re-instate” changesmade to a document. For example, in MICROSOFT WORD, a user can use an“undo” and “redo” function available from the standard toolbar to “undo”a change that was previously made or “redo” a change that was previouslyundone. This function can be performed multiple times. In other words,activating “undo” four times will undo the last four changes made to adocument. Subsequently activating “redo” three times will redo three ofthose last four changes, effectively resulting in the same effect asactivating “undo” once.

When performing certain types of tasks, such as performing certain typesof programming projects using certain editors, the editor may openseveral documents. When a user edits or changes one document, changesare made to the other document or documents automatically to reflect thechanges the user made to the first document. Typically, however, theundo/redo function does not extend across multiple documents. Henceproblems may arise when, for example, an element is deleted from adocument and then the delete function is undone. The element may bedeleted in the first document and then be reinstated to its originalcondition (by the undo) but the corresponding changes to the relateddocument may not be made, so that the related document is not properlyreinstated to its original condition.

For example, in an active server page (ASP) file declarative tags (HTML,ASP directives, server controls and static text, and the user interface(UI) part) are combined with the code. In certain environments, the codeeither can be stored on the same page as the tags or on a separate pageknown herein as the Code-Behind page. When an element such as a controlis deleted in the UI component, associated elements such as thedeclaration, events and properties of the control are deleted from thecode file. Problems arise, however, for example, when the delete isundone. When the delete is undone, the declaration, properties andevents should be reapplied to the related Code-Behind file, however,heretofore, no known method has been available to apply the undo (orundo/redo, etc.) to the related document because the undo/redo functionhas been confined to a single document. Hence it would be helpful if anundo/redo function could support undo/redo changes across multipledocuments.

SUMMARY

Editing operations are monitored for operations for which informationmust be stored in order to properly apply an undo, redo, or undo/redosequence or the like to a plurality of files. A snapshot is taken andpersisted before such an operation is performed. Upon the execution ofan undo or redo command, the persisted snapshot is retrieved and appliedto the newly generated editing element. Hence editing operations such asbut not limited to undo/redo operations are performed essentiallysimultaneously to multiple files, wherein an editing operation such asan undo, a redo or the like, performed on one file is propagated to arelated file or files automatically.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing summary, as well as the following detailed description ofpreferred embodiments, is better understood when read in conjunctionwith the appended drawings. For the purpose of illustrating theinvention, there is shown in the drawings exemplary constructions of theinvention; however, the invention is not limited to the specific methodsand instrumentalities disclosed. In the drawings:

FIG. 1 is a block diagram of an exemplary computing environment in whichaspects of the invention may be implemented;

FIG. 2 is a block diagram of an undo/redo system in accordance with oneembodiment of the invention;

FIG. 3 is a block diagram illustrating an active server page (prior art)and a WebForm and Code-Behind File in accordance with one embodiment ofthe present invention;

FIG. 4 illustrates an exemplary blank WebForm;

FIG. 5 illustrates the exemplary WebForm of FIG. 3 to which a button hasbeen added;

FIG. 6 illustrates an exemplary Code-Behind file generated by the VISUALSTUDIO design editor;

FIG. 7 illustrates the exemplary WebForm of FIG. 4 which has had thebutton of FIG. 4 deleted;

FIG. 8 illustrates the exemplary Code-Behind file reflecting thedeletion of the button;

FIG. 9 illustrates the exemplary WebForm of FIG. 4 which has had thedeletion of the button undone;

FIG. 10 illustrates the exemplary Code-Behind file that results from aneditor that does not support multiple undo/redo across multipledocuments;

FIG. 11 illustrates the exemplary Code-Behind file that results from aneditor that supports multiple undo/redo across multiple documents inaccordance with one embodiment of the invention; and

FIG. 12 is a flow diagram of an undo/redo method in accordance with oneembodiment of the invention.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS Exemplary ComputingEnvironment

FIG. 1 and the following discussion are intended to provide a briefgeneral description of a suitable computing environment in which theinvention may be implemented. It should be understood, however, thathandheld, portable, and other computing devices of all kinds arecontemplated for use in connection with the present invention. While ageneral purpose computer is described below, this is but one example,and the present invention requires only a thin client having networkserver interoperability and interaction. Thus, the present invention maybe implemented in an environment of networked hosted services in whichvery little or minimal client resources are implicated, e.g., anetworked environment in which the client device serves merely as abrowser or interface to the World Wide Web.

Although not required, the invention can be implemented via anapplication programming interface (API), for use by a developer, and/orincluded within the network browsing software which will be described inthe general context of computer-executable instructions, such as programmodules, being executed by one or more computers, such as clientworkstations, servers, or other devices. Generally, program modulesinclude routines, programs, objects, components, data structures and thelike that perform particular tasks or implement particular abstract datatypes. Typically, the functionality of the program modules may becombined or distributed as desired in various embodiments. Moreover,those skilled in the art will appreciate that the invention may bepracticed with other computer system configurations. Other well knowncomputing systems, environments, and/or configurations that may besuitable for use with the invention include, but are not limited to,personal computers (PCs), automated teller machines, server computers,hand-held or laptop devices, multi-processor systems,microprocessor-based systems, programmable consumer electronics, networkPCs, minicomputers, mainframe computers, and the like. The invention mayalso be practiced in distributed computing environments where tasks areperformed by remote processing devices that are linked through acommunications network or other data transmission medium. In adistributed computing environment, program modules may be located inboth local and remote computer storage media including memory storagedevices.

FIG. 1 thus illustrates an example of a suitable computing systemenvironment 100 in which the invention may be implemented, although asmade clear above, the computing system environment 100 is only oneexample of a suitable computing environment and is not intended tosuggest any limitation as to the scope of use or functionality of theinvention. Neither should the computing environment 100 be interpretedas having any dependency or requirement relating to any one orcombination of components illustrated in the exemplary operatingenvironment 100.

With reference to FIG. 1, an exemplary system for implementing theinvention includes a general purpose computing device in the form of acomputer 110. Components of computer 110 may include, but are notlimited to, a processing unit 120, a system memory 130, and a system bus121 that couples various system components including the system memoryto the processing unit 120. The system bus 121 may be any of severaltypes of bus structures including a memory bus or memory controller, aperipheral bus, and a local bus using any of a variety of busarchitectures. By way of example, and not limitation, such architecturesinclude Industry Standard Architecture (ISA) bus, Micro ChannelArchitecture (MCA) bus, Enhanced ISA (EISA) bus, Video ElectronicsStandards Association (VESA) local bus, and Peripheral ComponentInterconnect (PCI) bus (also known as Mezzanine bus).

Computer 110 typically includes a variety of computer readable media.Computer readable media can be any available media that can be accessedby computer 110 and includes both volatile and nonvolatile media,removable and non-removable media. By way of example, and notlimitation, computer readable media may comprise computer storage mediaand communication media. Computer storage media includes both volatileand nonvolatile, removable and non-removable media implemented in anymethod or technology for storage of information such as computerreadable instructions, data structures, program modules or other data.Computer storage media includes, but is not limited to, RAM, ROM,EEPROM, flash memory or other memory technology, CDROM, digitalversatile disks (DVD) or other optical disk storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other medium which can be used to store the desired informationand which can be accessed by computer 110. Communication media typicallyembodies computer readable instructions, data structures, programmodules or other data in a modulated data signal such as a carrier waveor other transport mechanism and includes any information deliverymedia. The term “modulated data signal” means a signal that has one ormore of its characteristics set or changed in such a manner as to encodeinformation in the signal. By way of example, and not limitation,communication media includes wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, RF,infrared, and other wireless media. Combinations of any of the aboveshould also be included within the scope of computer readable media.

The system memory 130 includes computer storage media in the form ofvolatile and/or nonvolatile memory such as read only memory (ROM) 131and random access memory (RAM) 132. A basic input/output system 133(BIOS), containing the basic routines that help to transfer informationbetween elements within computer 110, such as during start-up, istypically stored in ROM 131. RAM 132 typically contains data and/orprogram modules that are immediately accessible to and/or presentlybeing operated on by processing unit 120. By way of example, and notlimitation, FIG. 1 illustrates operating system 134, applicationprograms 135, other program modules 136, and program data 137.

The computer 110 may also include other removable/non-removable,volatile/nonvolatile computer storage media. By way of example only,FIG. 1 illustrates a hard disk drive 141 that reads from or writes tonon-removable, nonvolatile magnetic media, a magnetic disk drive 151that reads from or writes to a removable, nonvolatile magnetic disk 152,and an optical disk drive 155 that reads from or writes to a removable,nonvolatile optical disk 156, such as a CD ROM or other optical media.Other removable/non-removable, volatile/nonvolatile computer storagemedia that can be used in the exemplary operating environment include,but are not limited to, magnetic tape cassettes, flash memory cards,digital versatile disks, digital video tape, solid state RAM, solidstate ROM, and the like. The hard disk drive 141 is typically connectedto the system bus 121 through a non-removable memory interface such asinterface 140, and magnetic disk drive 151 and optical disk drive 155are typically connected to the system bus 121 by a removable memoryinterface, such as interface 150.

The drives and their associated computer storage media discussed aboveand illustrated in FIG. 1 provide storage of computer readableinstructions, data structures, program modules and other data for thecomputer 110. In FIG. 1, for example, hard disk drive 141 is illustratedas storing operating system 144, application programs 145, other programmodules 146, and program data 147. Note that these components can eitherbe the same as or different from operating system 134, applicationprograms 135, other program modules 136, and program data 137. Operatingsystem 144, application programs 145, other program modules 146, andprogram data 147 are given different numbers here to illustrate that, ata minimum, they are different copies. A user may enter commands andinformation into the computer 110 through input devices such as akeyboard 162 and pointing device 161, commonly referred to as a mouse,trackball or touch pad. Other input devices (not shown) may include amicrophone, joystick, game pad, satellite dish, scanner, or the like.These and other input devices are often connected to the processing unit120 through a user input interface 160 that is coupled to the system bus121, but may be connected by other interface and bus structures, such asa parallel port, game port or a universal serial bus (USB).

A monitor 191 or other type of display device is also connected to thesystem bus 121 via an interface, such as a video interface 190. Agraphics interface 182, such as Northbridge, may also be connected tothe system bus 121. Northbridge is a chipset that communicates with theCPU, or host processing unit 120, and assumes responsibility foraccelerated graphics port (AGP) communications. One or more graphicsprocessing units (GPUs) 184 may communicate with graphics interface 182.In this regard, GPUs 184 generally include on-chip memory storage, suchas register storage and GPUs 184 communicate with a video memory 186.GPUs 184, however, are but one example of a coprocessor and thus avariety of coprocessing devices may be included in computer 110. Amonitor 191 or other type of display device is also connected to thesystem bus 121 via an interface, such as a video interface 190, whichmay in turn communicate with video memory 186. In addition to monitor191, computers may also include other peripheral output devices such asspeakers 197 and printer 196, which may be connected through an outputperipheral interface 195.

The computer 110 may operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computer180. The remote computer 180 may be a personal computer, a server, arouter, a network PC, a peer device or other common network node, andtypically includes many or all of the elements described above relativeto the computer 110, although only a memory storage device 181 has beenillustrated in FIG. 1. The logical connections depicted in FIG. 1include a local area network (LAN) 171 and a wide area network (WAN)173, but may also include other networks. Such networking environmentsare commonplace in offices, enterprise-wide computer networks, intranetsand the Internet.

When used in a LAN networking environment, the computer 110 is connectedto the LAN 171 through a network interface or adapter 170. When used ina WAN networking environment, the computer 110 typically includes amodem 172 or other means for establishing communications over the WAN173, such as the Internet. The modem 172, which may be internal orexternal, may be connected to the system bus 121 via the user inputinterface 160, or other appropriate mechanism. In a networkedenvironment, program modules depicted relative to the computer 110, orportions thereof, may be stored in the remote memory storage device. Byway of example, and not limitation, FIG. 1 illustrates remoteapplication programs 185 as residing on memory device 181. It will beappreciated that the network connections shown are exemplary and othermeans of establishing a communications link between the computers may beused.

One of ordinary skill in the art can appreciate that a computer 110 orother client device can be deployed as part of a computer network. Inthis regard, the present invention pertains to any computer systemhaving any number of memory or storage units, and any number ofapplications and processes occurring across any number of storage unitsor volumes. The present invention may apply to an environment withserver computers and client computers deployed in a network environment,having remote or local storage. The present invention may also apply toa standalone computing device, having programming languagefunctionality, interpretation and execution capabilities.

Undo/Redo System and Method

Overview

FIG. 2 is a block diagram illustrating an exemplary system for multipleundo/redo operations across multiple files in accordance with oneembodiment of the invention. Within an Integrated Design Environment(IDE) 214, a Design Editor 216 supports the editing of multipledocuments (e.g., a WebForm file 300 and a Code-Behind file 500.) It willbe understood that any particular files may be substituted for WebFormFile 300 and Code-Behind file 500. The files chosen are exemplary only.The files may be homogeneous (i.e., the same type of file, e.g., twoword-processing documents) or heterogeneous (i.e., different, e.g., aWebForm and a Code-Behind file). Additionally, although two files areused in the example, the invention contemplates that any number of filesmay be the subject of the undo/redo. Similarly, the Design Editor 216may be any suitable editor including but not limited to a source codeeditor or a word processing program and may exist within any suitableenvironment 214. Finally, although the invention is described in thecontext of undo and redo operations, and sequences of undo/redo orredo/undo operations, other editing operations requiring the capture ofadditional information are contemplated by the invention.

When an editing operation is performed on an element (element one) in afirst file, the editing operation associated with another element(element two) in a related file or files, a notification is sent to alistener object such as Listener Manager 218. If the operation is onefor which information must be captured in order for an undo or a redo tobe correctly performed, a snapshot (element three) of an aspect ofelement one of the first file or a snapshot of element two from therelated file or files is taken by a serializer/deserializer 220 beforethe selection is operated on. The snapshot is stored in a snapshotstore. In one embodiment, the snapshot is stored as an object in anobject store 222. An operation unit including the operation and theelement on which the operation was performed is added to an operationstore 224. If an operation such as, for example, an “undo” is received,the appropriate operation and element are retrieved from the operationstore 224, the snapshot is retrieved from the snapshot store and appliedto the element of the first file to generate the element of the secondfile or the snapshot of the second element is retrieved from thesnapshot store and is applied to the related file or files. An operationunit (e.g., custom undo unit) for the undo is stored in an operationstore 224 maintained by Listener Manager 218.

For example, assume that two homogeneous or heterogeneous documents arebeing simultaneously edited and that document 1 is associated with ablock of text comprising the words “Software Version 1.0”. Assumefurther that the words “Software Version 1.0” are associated with thewords “MixItWell Package” in document 2. If an editing operation such as“delete” or “cut” of “Software Version 1.0” is received, typically,“Software Version 1.0” will be deleted from document 1 and “MixItWellPackage” will be deleted from document 2. In accordance with oneembodiment of the invention, before “Software Version 1.0” is deletedfrom document 1 and before “MixItWell Package” is deleted from document2, a notification is sent to Listener Manager 218 so that a snapshot of“MixItWell Package” is taken and stored in a snapshot store so that ifthe deletion of “Software Version 1.0” is undone, restoring “SoftwareVersion 1.0” to document 1, “MixItWell Package” is likewise restored todocument 2.

In this case receipt of a undo delete command would result in “SoftwareVersion 1” being re-instated in document 1 and “MixItWell Package” beingretrieved from the snapshot store and re-applied to document 2. Anoperation unit is added to the operation store 224. The operation unitincludes an identifier of the edited element (e.g., “Software Version 1”and the operation performed (e.g., delete undo).

Undo/Redo Across Multiple Files in the .NET Environment

One of the four major pieces of the .NET framework is ASP.NET, thesuccessor to Active Server Pages (ASP). ASP.NET is a programmingenvironment for Web applications that run on the Internet InformationServices (IIS) Web server and interact with users through a browser.ASP.NET loads dynamic Web pages, parses the pages for .NET code (i.e.,code written in Visual Basic.NET, C#, JScript, or other .NET languages),and passes the code along to .NET language compilers and the CLR (CommonLanguage Runtime). ASP.NET supports the CLR libraries, and languages.

ASP.NET reduces the amount of code required to write a Web applicationor Web service and introduces new methods for implementing Web services.Additional information concerning the .NET platform produced byMicrosoft Corporation of Redmond, Wash. is described in PCT PublicationWO 01/98936, having an international filing date of Jun. 22, 2001 andincorporated herein by reference.

ASP.NET developers create pages by assembling and customizing the WebForms controls provided by the class libraries. Developers customizecontrols by setting properties, such as but not limited to font, size,placement and by supplying application-specific “event handler” code.This code is invoked upon each user request or response. Developers canalso create custom controls, which could allow commercial independentsoftware vendors (ISVs) to offer add-on libraries of ASP.NET controlssimilar to the libraries of ActiveX controls available for Visual Basictoday.

Visual Studio Integrated Development Environment (IDE)

Visual Studio.NET provides tools including an editor for writing sourcecode and wizards that automatically generate source code for commonprogramming tasks. For example, developers can automatically generatethe code required to call a Web service by dragging and dropping a linkto the Web service site into the client application's source code in theIDE. Graphical editors in Visual Studio.NET enable developers to buildWeb Forms by dragging and dropping fields and other components from atoolbox. Visual Studio.NET provides a single Integrated DesignEnvironment (IDE) that supports all of its programming languages andcovers Web applications and desktop applications.

FIG. 3 illustrates an active server page (ASP) file and a WebForm andCode-Behind file. Typically, the creation of an ASP page 200 requiresthe efforts of both a UI designer who controls the appearance of thepage using tags such as HTML 206, 210, etc. and a developer who controlsthe informational processing of the page using in-line script or code208, 212. Hence the ASP 200 typically includes UI HTML 206, 210intermingled with code 208, 212. Typically, during development thissingle file (i.e., ASP 200) is modified by at least two individuals, theUI designer and the code developer. A number of inconveniences andpotential problems might be expected in this scenario. For example, thedesigner and the developer would not be able to work concurrently on thesame file and the page tends to become unreadable because HTML isintermingled with in-line script. Additionally, the opportunity for oneperson to make changes that adversely affect the other person's workexists.

Hence the .NET platform enables the separation of the UI portion 202(called a Web form and preferably denoted by a file extension of “aspx”or “ascx”) of the ASP.NET page from the code part 204 (preferablydenoted by a file extension of “cs” if the code is written in C# or“vb”, if the code is written in Visual Basic). The file that containsthe code part is called herein the “Code-Behind” or “Code-Beside” file.At runtime, the two files are compiled into one file.

Within the Design Editor 216 of the IDE 214, an ASP.NET developer cancreate a page by assembling and customizing the Web Forms controlsprovided by the class libraries. A Web Form control is a componentembedded in a Web page and that runs on a Web server. When a page isaccessed, the Web Forms controls embedded in the page accept andvalidate the user's input and generate the appropriate HTML output inresponse. Web Forms controls include simple form input fields andbuttons and complex elements such as a grid control that enables usersto view and edit live database data as is done, for example, in aspreadsheet like Excel. Web Forms provide built-in code to handle commontasks such but not limited to:

Validating input data (e.g., preventing a user from entering lettersinto a “quantity” field).

Keeping track of page state and displaying the state appropriately whenthe user refreshes the page in the browser (e.g., input field controlsdisplay their last entered value).

Determining what browser version the user has and adapting output tothat browser.

A developer can customize a control by setting the properties ofprovided controls. The properties used for customization may include butare not limited to font, size, and placement. Controls can also becustomized by supplying application-specific “event handler” code whichis invoked upon a user request or response. A developer can also createa custom control, (e.g., a custom control may be developed by acommercial independent software vendor (ISV) so that add-on libraries ofASP.NET controls could be added similar to the libraries of ActiveXcontrols available for Visual Basic today).

Typically, a control is uniquely identified in the Code-Behind fileusing the attribute ID (e.g., ID=Button1 might identify a first buttonon a page.) Hence in the Code-Behind file a declaration for the controlwill exist, as will events and properties associated with the control.Each event is associated with an event handler. During runtime, aninstance of a class (e.g., an instance of a Button class) is generatedfor each control. The instance of a class (the object) is associatedwith the defined properties such as ID (e.g., Button1), backcolor (e.g.,red), text (e.g., “Hello”), an event (e.g., a click event) and so on.

Now assume that two heterogeneous files are being edited, where thefirst file is a WebForm document 300 and the second file is theCode-Behind file 500. It should be understood that while in this examplethe two files are heterogeneous, the files in question couldalternatively be homogeneous files. Assume that WebForm document 300includes a control 402. Control 402 may be associated with state, thatis, particular values to which characteristics or properties of thecontrol have been set. The state of the control may be associated withparticular code in Code-Behind file 500 such as a ClickEvent and eventhandler. Assume that user input has been received that indicates that anediting operation (e.g., a delete of control 402) has been received.Before the control is deleted from the WebForm document 300 and the codeassociated with the state of the control is deleted from the Code-Behindfile 500, a notification is sent to a listener object (e.g., ListenerManager 218) and a snapshot of the state of the control being deleted istaken by the serializer/deserializer 220 and stored (e.g., as an object)in a snapshot store, (e.g., object store 222).

For example, if the input received indicates that the control 402 (e.g.,Button1) is to be deleted from WebForm 300, a notification is sent toListener Manager 218 so that before Button1 is deleted from the form, asnapshot of the state of Button1 is taken by the serializer/deserializer220 and stored as an object in object store 222.

Thus, it should be understood that any element or any aspect of theelement may be captured by the snapshot. The use of state in the exampleabove is merely exemplary. In one embodiment, operations on an elementfor which a snapshot is required (e.g., cut, delete and the like) may bedetermined by the presence of an “accountable” attribute, but anysuitable method of determining such operations is contemplated by theinvention. Similarly, it should be understood thatserializer/deserializer 220 may be any appropriate module capable ofcapturing an element or aspect of an element, such as but not limitedto, the state of a control. The captured element or aspect of anelement, in one embodiment of the invention, is a code object and isstored in an object store 222 but it should be understood that theelement or aspect of the element may be captured as an object, codeobject, string, XML, BLOB or in any other suitable fashion and may bestored in any suitable store. An operation unit (e.g. custom undo unit)that identifies an editing operation on an element is stored in anoperation store 224. In one embodiment of the invention, the operationstore 224 is a LIFO stack. The operation store 224 may include differentkinds of operations (e.g., both undo and redo operations and the like)or one store may be maintained for each different type of operation(e.g., undo operations may be stored in an undo store and redooperations may be stored in a redo store).

For example, if an undo is subsequently received for the deletion ofButton1, a new instance of Button1 is re-instated in WebForm document300, the pre-deletion state of Button1 is retrieved by retrieving thesnapshot stored in object store 222 for Button1, the retrieved codeobject is applied to Button1 and the resultant code is applied toCode-Behind file 500. An operation unit that identifies Button1 (thecontrol that was deleted) and the operation (undo delete) is added tothe operation store 224. An operation unit is added to the operationstore 224 so that a subsequent redo operation can be performed, ifrequested. While the examples above have detailed a delete operationfollowed by an undo, it should be understood that other operationsrequiring the capture of additional information such as state of acontrol are contemplated by the invention (e.g., the redo of an “undone”operation or any sequence of undo/redo operations or the like).

For example, and referring now to FIG. 4, a blank default WebFormdocument 300, containing no controls, etc. is illustrated. FIG. 5illustrates the WebForm document 300 to which a Button server control(Button1) 402 was added from the toolbox 404. The control is selected bydefault after being inserted into the document 300. Upon double-clickingon the button 402 (or by selecting the control and pressing the “Enter”key) a default event handler for the control is generated and a windowdisplaying the code-behind is displayed. In the case of the Buttonserver control 402, a Click handler is generated. FIG. 6 illustrates thecode-behind document 500. The declaration 504 for Button1 402 isillustrated. Code for the event handler that was generated as a resultof the double-click action is referenced by reference numeral 502. The“Handles” clause 502 a is the way the event handler function is hookedto the corresponding control in VisualBasic (in this case Button1, 402).

FIG. 7 illustrates WebForm document 300 in which Button1 402 has beenselected and deleted. Switching back to the Code-Behind document 500illustrated in FIG. 8, it can be seen that the declaration for Button1,504 has been removed and the event hookup (“Handles” clause 502 a) hasbeen removed. Thus, the Button1_Click function is an orphaned function.

FIG. 9 illustrates WebForm document 300 after the “Edit” selection 802of the menu bar and the “undo typing” option was selected (not shown),control-z was entered, or the left arrow 804 on the icon bar wasclicked. It can be seen that Button1 402 has reappeared on document 300.Switching back to the Code-Behind document 500, illustrated in FIG. 10,it can be seen that, in the existing designer editor that does notsupport multiple undo/redo across documents, the Button declaration isback 902 but the Handles Clause is still gone. Hence, the Button1_Clickfunction is still an orphaned function and is not hooked up to theButton1 control. Referring now to FIG. 11, it can be seen that, in thedesigner editor 216 of the present invention, which supports multipleundo/redo across documents, the Button1 declaration 1004 is back and the“Handles” Clause 1002 a is also back.

FIG. 12 illustrates a method for performing a multiple undo/redo inaccordance with one embodiment of the invention. At step 1202, a filesuch as, but not limited to a document, is opened by an editor inaccordance with the present invention. A related file or files is alsoopened. The files may be related implicitly or explicitly. The relatedfiles may be opened automatically by the editor or may be selected to beopened by the user. At step 1204 the file is edited. The associated fileor files may also be automatically modified. In one embodiment theeditor may make the same changes made to the first file to the relatedfile or files or alternatively, the editor may make changes that are notthe same but are determined by the changes made to the first file to therelated file or files. If, at step 1206, it is determined that theoperation performed is one that may be the object of a subsequent undoor redo or the like and that operation would require saving informationin order to properly apply the operation to the related file or files, asnapshot of the information is taken at step 1208. (Non-limitingexamples of operations that might require the saving of additionalinformation are delete and cut operations. A non-limiting example ofinformation to be captured is the saving of current state of an elementsuch as a control.) At step 1210 the snapshot is stored in a snapshotstore. In one embodiment of the invention, the snapshot store is a hashtable keyed on element identifier and includes element identifier andthe serialized code object capturing the pre-operation state of theelement. At step 1212 an operation unit identifying the operation andthe element on which the operation operates is added to an operationstore. In one embodiment the operation store is a last-in-first-out(LIFO) stack but any suitable storage mechanism may be used. In oneembodiment the stack will include various operations. In anotherembodiment of the invention, different operations are stored indifferent stacks. If at step 1206, the operation is not an operation onan element that requires saving information, at step 1214 it isdetermined if the operation is an undo or a redo operation or the like.If the operation is not an undo or a redo operation or the like,processing continues at step 1204. If the operation is an undo or a redooperation or the like, the operation store is accessed, the appropriateoperation unit is called (step 1215) and the operation and the elementto be undone or redone is determined. Corresponding saved informationfrom the snapshot store is retrieved (step 1216). The undo or redo isapplied to the first file, the information retrieved from the snapshotstore (i.e., the third element) is applied to the element (i.e., thefirst element) operated on and the result (i.e., the second element) isapplied to the related file or files. Alternatively, the snapshot (i.e.,the second element) is retrieved from the snapshot store and applieddirectly to the related file or files. The operation unit identifyingthe undo or redo operation and the element operated on is added to theappropriate operation store at step 1218. Processing continues at step1204.

Referring again to FIG. 12, for example, at step 1202, the Design Editor216 is accessed and WebForm document 300 is opened. Assume that WebFormdocument 300 includes Button1 402 (element one). Preferably, associatedCode-Behind document 500 is also opened automatically by the DesignEditor 216. Assume that associated Code-Behind file 500 contains adeclaration 504 and an event 502 associated with Button1 402,automatically placed in Code-Behind file 500 by Design Editor 216 as aresult of adding Button1 402 in WebForm 300. The event 502 is associatedwith an event handler clause 502 a. Event 502 and event handler clause502 a comprise particular code (element two) of Code-Behind file 500associated with Button1 (element one) of WebForm document 300.

At step 1204, an editing operation is performed. For example, assumethat a button is moved from one location to another within document 300,or background color is changed. At step 1206, a notification is sent toListener Manager 218. Listener Manager 218 determines that this editingoperation is not one that requires additional information such as stateto be saved. At step 1214, it is determined that this is not an undo orredo operation so processing returns to step 1204. At step 1204 acontrol (e.g., Button1 402) is selected and deleted. At step 1206, anotification is sent to Listener Manager 218. In one embodiment, achange service notification (e.g., OnComponentRemoving) is used todetect that a control (i.e., Button1) is being removed from the WebFormdocument 300. Preferably notifications fired as part of destroying orclosing document 300 are ignored. It is determined that this is anoperation for which state needs to be saved, so processing continues atstep 1208.

At step 1208, a snapshot is taken. In one embodiment the snapshot istaken by calling a module (e.g., CodeDomSerializer.Serialize) on theserializer associated with the type of control, (in this case, a Buttoncontrol). At step 1210 the snapshot is stored. In one embodiment, thesnapshot is a code object generated by the serializer. In one embodimentthe code object is stored in a hash table keyed off the uniqueidentifier of the control (e.g., Button1). The hash table includes thekey (Button1) and a value (the code object).

An operation unit is added to the operation store at step 1212. In oneembodiment the Undo/Redo Manager keeps track of operations than can beundone or redone by maintaining a LIFO (last in first out) stack of undoand redo units. Every editing operation that can be undone generates anundo unit. Every undo operation generates a redo unit. Hence, when anelement such as Button1 is deleted, a parent undo unit is created and isadded to the stack of undo units. When the notification is fired, a newinstance of a custom undo unit (i.e., an operation unit) is created. Thepre-made operation unit itself may be customized or overridden. Theoperation unit is created to hold the code-behind data (e.g., the stateof Button1) from Code-Behind document 500 and in one embodiment is addedas a child of the parent undo unit created when Button1 was deleted fromWebForm document 300. In one embodiment, the child undo unit is added tothe parent undo unit through IOleUndoManager.Add. In one embodiment,operation units cache the code object and respective code DOMserializer(s) and do not hold references to live controls or to theircorresponding designer instances.

Processing returns to step 1204. Assume that the next editing operationthat is performed is “undo”, that is, just-deleted Button1 is to bere-instated in WebForm 300. When Button1 is regenerated by the undo,Button1 does not have the original properties associated with it in theCode-Behind file. At step 1206 it is determined that the editingoperation is not an operation requiring state to be stored, andprocessing proceeds to step 1214. At step 1214 it is determined that theediting operation is an undo or redo. The editing operation is undone onthe first file. In one embodiment a notification is sent that preferablyincludes the unique ID (Button), and the operation (undo). In oneembodiment, this notification is a call to IOleUndoUnit::Do. At step1215, the appropriate operation unit is retrieved. (e.g., throughIOleUndoUnit::Do). In one embodiment Undo/Redo Manager implements theundo. Undo/Redo Manager retrieves the operation unit from the operationstore and calls IOleUndoUnit::Do. IOleUndoUnit::Do places the newoperation (undo) unit on a redo stack and adds Button1 back to WebFormdocument 300. When Button1 is regenerated by Undo/Redo Manager, Button1does not have the original properties associated with it in theCode-Behind file. At step 1216 a notification is sent indicating that acontrol whose unique ID is “Button1” has been added to WebForm 300. Inone embodiment the cached code-behind information is retrieved from thehash table from the unique key (e.g., Button1) and the state stored inthe code object is applied on the appropriate control instance bycalling CodeDomSerializer.Deserialize. Deserialization applies the statestored in the code object to an instance (e.g., Button1). Hence, thecode object that the serializer returned in step 1208 is retrieved fromthe hash table and the deserializer applies the properties stored in thecode object to the Button1 control. Preferably, the code object can beapplied to the same instance or to a different instance of the same typeof control.

Hence Button1 (element one) is added back to WebForm 300, and theappropriate code (element two) is added back to Code-Behind file 500. Atstep 1218, the undo operation unit is added to the operation store. Inone embodiment the operation unit is added to the operation store bycalling IOleUndoManager.Add). The operation unit is added to theoperation store so that the operation can be redone, if desired. Itshould be understood that although the example demonstrated a delete andan undo, an undo and a redo, any combination of undos and redos or thelike may be performed, limited only by the size of the operation storeor stores. Processing continues at step 1204.

CONCLUSION

It is noted that the foregoing examples have been provided merely forthe purpose of explanation and are in no way to be construed as limitingof the present invention. While the invention has been described withreference to various embodiments, it is understood that the words whichhave been used herein are words of description and illustration, ratherthan words of limitation. Further, although the invention has beendescribed herein with reference to particular means, materials andembodiments, the invention is not intended to be limited to theparticulars disclosed herein; rather, the invention extends to allfunctionally equivalent structures, methods and uses, such as are withinthe scope of the appended claims. Those skilled in the art, having thebenefit of the teachings of this specification, may effect numerousmodifications thereto and changes may be made without departing from thescope and spirit of the invention in its aspects.

1. A computer-implemented method for performing a plurality of editingoperations on a plurality of files simultaneously, the methodcomprising: a computer opening the plurality of files, the plurality offiles comprising at least a first file comprising a user interface fileand a first element, and a second file comprising a Code-Behind filethat is separate from but related to the first file and comprising asecond element that is different than but related to the first elementof the first file such that an editing operation performed on the firstelement of the first file requires an editing operation to be performedon the corresponding second element of the second file; the computerreceiving a notification that a first editing operation is to beperformed on the first element of the first file, wherein performance ofthe first editing operation on the first element of the first file willresult in a second editing operation being automatically performed onthe corresponding second element of the second file; upon receiving thenotification, the computer determining whether the first editingoperation is one that is capable of being reversed, and when the firstediting operation is capable of being reversed, automatically capturingthe pre-operation state of at least the second element in the secondfile within persistent storage and storing within an operation store anoperation unit representative of the operation and state of theoperation performed for the first element and the second element; afterthe first editing operation has been performed on the first element ofthe first file and the second editing operation has been automaticallyperformed on the corresponding second element of the second file, thecomputer receiving a command to reverse the first editing operation onthe first element of the first file; and in response to the command, thecomputer automatically retrieving the pre-operation state of the secondelement of the second file and the operation performed on the secondelement from the operation store and applying the retrieved state andoperation of the second element to the second file to automaticallyreverse the second operation performed on the second element, whereinthe reverse operation comprises reapplying the state and operation onthe second element and storing the operation unit and operation statefor the reverse operation in persistent storage.
 2. The method of claim1, wherein the command is one of an undo operation or a redo operationand the command produces changes that are not the same for a userinterface file as they are for a Code-Behind file.
 3. The method ofclaim 1, wherein performing the first editing operation on the firstelement in the first file further comprises: in response to determiningthat the first element is not the same as the second element, persistingthe second element in a first store.
 4. The method of claim 1, whereinin response to determining that the first element is not the same as thesecond element, the computer persisting a third element and anidentifier of the first element in a first store within the persistentstorage.
 5. The method of claim 4, wherein the second element is thesame as the third element.
 6. The method of claim 4, wherein the secondelement is generated by applying the third element to the first element.7. The method of claim 4, wherein the first store is a hash table, keyedon a first element identifier.
 8. The method of claim 4, furthercomprising adding an operation unit identifying the first editingoperation and an identifier of the first element to an operation storewithin the persistent storage.
 9. The method of claim 1, wherein inresponse to receiving the command, the method further comprises: thecomputer retrieving an operation unit state associated with the firstediting operation from an operation store, wherein the operation unitstate comprises an element identifier and associated state for theelement; the computer retrieving an identifier of the first element fromthe operation unit state; the computer retrieving the pre-operationstate of the second element associated with the identifier of the firstelement from the persistent storage; and the computer applying thesecond element to the second file.
 10. The method of claim 4, wherein inresponse to receiving the command, the method further comprises: thecomputer retrieving an operation unit state associated with the firstediting operation from an operation store, wherein the operation unitstate comprises an element identifier and associated state for theelement; the computer retrieving an identifier of the first element fromthe operation unit state; the computer retrieving the third elementassociated with the identifier of the first element from the firststore; the computer applying the third element to the first element togenerate the second element; and the computer applying the secondelement to the second file.
 11. The method of claim 10, furthercomprising the computer adding a second operation unit to the operationstore, the second operation unit identifying the command and theidentifier of the first element to an operation stack.
 12. The method ofclaim 1, wherein the plurality of files are documents.
 13. The method ofclaim 1, wherein the first file is a WebForm and the second file is aCode-Behind file.
 14. The method of claim 1, wherein the first editingoperation is one of a delete or a cut.
 15. The method of claim 1,wherein the first element is a control.
 16. The method of claim 1,wherein the second element is a state of the control.
 17. The method ofclaim 16, wherein a serializer persists the state of the control as oneof a code object, XML, string or BLOB.
 18. A computer-readable storagemedium including computer-readable instructions for performing aplurality of editing operations on a plurality of files simultaneously,the instructions, when executed on a computer, causing the computer to:open the plurality of files, the plurality of files comprising at leasta first file comprising a user interface file and a first element, and asecond file comprising a Code-Behind file that is separate from butrelated to the first file and comprising a second element that isdifferent than but related to the first element of the first file suchthat an editing operation performed on the first element of the firstfile requires an editing operation to be performed on the correspondingsecond element of the second file; receive a notification that a firstediting operation is to be performed on the first element of the firstfile, wherein performance of the first editing operation on the firstelement of the first file will result in a second editing operationbeing automatically performed on the corresponding second element of thesecond file; upon receiving the notification, determine whether thefirst editing operation is one that is capable of being reversed, andwhen the first editing operation is capable of being reversed,automatically capture the pre-operation state of at least the secondelement in the second file within persistent storage and storing withinan operation store an operation unit representative of the operation andstate of the operation performed for the first element and the secondelement; after the first editing operation has been performed on thefirst element of the first file and the second editing operation hasbeen automatically performed on the corresponding second element of thesecond file, receive a command to reverse the first editing operation onthe first element of the first file; and in response to the command,automatically retrieve the pre-operation state of the second element ofthe second file and the operation performed on the second element fromthe operation store and apply the retrieved state and operation of thesecond element to the second file to automatically reverse the secondediting operation performed on the second element, wherein the reverseediting operation comprises reapplying the state and operation on thesecond element and storing the state and the operation unit for thereverse editing operation in persistent storage where an editing commandproduces changes that are not the same for the first file as they arefor the second file.
 19. The computer-readable medium of claim 18further comprising computer-readable instructions for: receiving arequest to perform a second operation on the first element in the firstfile; in response to determining that the second operation is one of anundo and a delete operation, retrieving the object identifying theoperation and the first element from the second store; retrieving thesecond element from the first store; and applying the second element tothe second file.
 20. A computing system comprising a processor and acomputing memory having stored therein instructions that when executedby the processor cause the computing system to: open the plurality offiles, the plurality of files comprising at least a first filecomprising a user interface file and a first element, and a second filecomprising a Code Behind file that is separate from but related to thefirst file and comprising a second element that is different than butrelated to the first element of the first file such that an editingoperation performed on the first element of the first file requires anediting operation to be performed on the corresponding second element ofthe second file; receive a notification that a first editing operationis to be performed on the first element of the first file, whereinperformance of the first editing operation on the first element of thefirst file will result in a second editing operation being automaticallyperformed on the corresponding second element of the second file; uponreceiving the notification, determine whether the first editingoperation is one that is capable of being reversed, and when the firstediting operation is capable of being reversed, automatically capturethe pre-operation state of at least the second element in the secondfile within persistent storage and storing within an operation store anoperation unit representative of the operation and state of theoperation performed for the first element and the second element; afterthe first editing operation has been performed on the first element ofthe first file and the second editing operation has been automaticallyperformed on the corresponding second element of the second file,receive a command to reverse the first editing operation on the firstelement of the first file; and in response to the command, automaticallyretrieve the pre-operation state of the second element of the secondfile and the operation performed on the second element from theoperation store and apply the retrieved state and operation of thesecond element to the second file to automatically reverse the secondediting operation performed on the second element, wherein the reverseediting operation comprises reapplying the state and operation on thesecond element and storing the state and the operation unit for thereverse editing operation in persistent storage where an editing commandproduces changes that are not the same for the first file as they arefor the second file.
 21. The computing system of claim 20 further havingstored therein instructions that when executed by the processor causethe computing system to: receive a request to perform a second operationon the first element in the first file; in response to determine thatthe second operation is one of an undo and a delete operation, retrievethe object identifying the operation and the first element from thesecond store; retrieve the second element from the first store; andapply the second element to the second file.